Industrial automation asset and control project analysis

ABSTRACT

An industrial development hub (IDH) supports industrial development and testing capabilities that are offered as a cloud-based service. The IDH comprises an enhanced storage platform and associated design tools that serve as a repository on which customers can store control project code, device configurations, and other digital aspects of an industrial automation project. The IDH system can facilitate discovery and management of digital content associated with control systems, and can be used for system backup and restore, code conversion, and version management.

BACKGROUND

The subject matter disclosed herein relates generally to industrialautomation systems, and, for example, to industrial programmingdevelopment platforms.

BRIEF DESCRIPTION

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

In one or more embodiments, a system for analyzing industrial controlprojects is provided, comprising a user interface component configuredto receive, from a client device via a cloud platform, an industrialcontrol project comprising at least control programming and deviceconfiguration data that, in response to execution on one or moreindustrial devices, facilitate monitoring and control of an industrialautomation system; a project telemetry component configured to generateproject telemetry data based on a first analysis of the industrialcontrol project, the project telemetry data defining characteristics ofthe one or more industrial devices and predicted operatingcharacteristics of the industrial control project inferred based on thefirst analysis; and a project analysis component configured to perform asecond analysis on the project telemetry data and to generate, based ona result of the second analysis, a recommendation for modifying theindustrial control project in a manner that improves one or more of thepredicted operating characteristics, wherein the user interfacecomponent is configured to render the recommendation on the clientdevice.

Also, one or more embodiments provide a method for analyzing industrialcontrol projects, comprising receiving, by a system comprising aprocessor via a cloud platform, an industrial control project comprisingat least control programming and device configuration data that, inresponse to execution on one or more industrial devices, facilitatemonitoring and control of an industrial automation system; generating,by the system, project telemetry data based on a first analysis of theindustrial control project, the project telemetry data definingcharacteristics of the one or more industrial devices and predictedoperating characteristics of the industrial control project inferredbased on the first analysis; generating, by the system based on a secondanalysis performed on the project telemetry data and to generate, arecommendation for modifying the industrial control project in a mannerthat improves one or more of the predicted operating characteristics;and rendering, by the system, the recommendation on a client device.

Also, according to one or more embodiments, a non-transitorycomputer-readable medium is provided having stored thereon instructionsthat, in response to execution, cause a system executing on a cloudplatform and comprising a processor to perform operations, theoperations comprising receiving, via a cloud platform, an industrialcontrol project comprising at least control programming and deviceconfiguration data that, in response to execution on one or moreindustrial devices, facilitate monitoring and control of an industrialautomation system; generating project telemetry data based on a firstanalysis of the industrial control project, the project telemetry datadefining characteristics of the one or more industrial devices andpredicted operating characteristics of the industrial control projectinferred based on the first analysis; generating, based on a secondanalysis performed on the project telemetry data and to generate, arecommendation for modifying the industrial control project in a mannerthat improves one or more of the predicted operating characteristics;and rendering the recommendation on a client device.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example industrial control environment.

FIG. 2 is a block diagram of an example industrial development hub (IDH)repository system.

FIG. 3 is a diagram illustrating a generalized architecture of the IDHrepository system.

FIG. 4 is a diagram illustrating example data flows associated withcreation of a new control project for an automation system beingdesigned using an IDH repository system.

FIG. 5 is a diagram illustrating several example automation objectproperties that can be leveraged by an IDH repository system inconnection with building, deploying, and executing a control project.

FIG. 6 is a diagram illustrating extraction of project telemetry datafrom a control project submitted to an IDH repository system.

FIG. 7 is a diagram illustrating generation of project recommendationsbased on analysis of extracted project telemetry data.

FIG. 8 is a diagram illustrating generation of project recommendationsbased on analysis of extracted project telemetry data.

FIG. 9 is a diagram illustrating generation of handoff documentation byan IDH repository system.

FIG. 10 is a diagram illustrating collection of digital signatures by anIDH repository system.

FIG. 11 is a diagram illustrating submission of a new version of acontrol project for archival with older project versions.

FIG. 12 is a diagram illustrating intelligent backup of deviceconfiguration data to an IDH repository system.

FIG. 13 is a diagram illustrating an example restore process that can beinitiated by through an IDH repository system.

FIG. 14 is a flowchart of an example methodology for providing real-timedesign feedback for an industrial control project during developmentusing a cloud-based IDH repository system.

FIG. 15a is a flowchart of a first part of an example methodology forperforming control project analytics on an uploaded control project andcollecting vendor-specific device usage statistics based on results ofthe analytics.

FIG. 15b is a flowchart of a second part of the example methodology forperforming control project analytics on an uploaded control project andcollecting vendor-specific device usage statistics based on results ofthe analytics.

FIG. 16 is an example computing environment.

FIG. 17 is an example networking environment.

DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding thereof. It may be evident, however, that the subjectdisclosure can be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate a description thereof.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “controller,” “terminal,” “station,” “node,”“interface” are intended to refer to a computer-related entity or anentity related to, or that is part of, an operational apparatus with oneor more specific functionalities, wherein such entities can be eitherhardware, a combination of hardware and software, software, or softwarein execution. For example, a component can be, but is not limited tobeing, a process running on a processor, a processor, a hard disk drive,multiple storage drives (of optical or magnetic storage medium)including affixed (e.g., screwed or bolted) or removable affixedsolid-state storage drives; an object; an executable; a thread ofexecution; a computer-executable program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components can reside within a processand/or thread of execution, and a component can be localized on onecomputer and/or distributed between two or more computers. Also,components as described herein can execute from various computerreadable storage media having various data structures stored thereon.The components may communicate via local and/or remote processes such asin accordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal). As another example, a component can be anapparatus with specific functionality provided by mechanical partsoperated by electric or electronic circuitry which is operated by asoftware or a firmware application executed by a processor, wherein theprocessor can be internal or external to the apparatus and executes atleast a part of the software or firmware application. As yet anotherexample, a component can be an apparatus that provides specificfunctionality through electronic components without mechanical parts,the electronic components can include a processor therein to executesoftware or firmware that provides at least in part the functionality ofthe electronic components. As further yet another example, interface(s)can include input/output (I/O) components as well as associatedprocessor, application, or Application Programming Interface (API)components. While the foregoing examples are directed to aspects of acomponent, the exemplified aspects or features also apply to a system,platform, interface, layer, controller, terminal, and the like.

As used herein, the terms “to infer” and “inference” refer generally tothe process of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

Furthermore, the term “set” as employed herein excludes the empty set;e.g., the set with no elements therein. Thus, a “set” in the subjectdisclosure includes one or more elements or entities. As anillustration, a set of controllers includes one or more controllers; aset of data resources includes one or more data resources; etc.Likewise, the term “group” as utilized herein refers to a collection ofone or more entities; e.g., a group of nodes refers to one or morenodes.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches also can be used.

FIG. 1 is a block diagram of an example industrial environment 100. Inthis example, a number of industrial controllers 118 are deployedthroughout an industrial plant environment to monitor and controlrespective industrial systems or processes relating to productmanufacture, machining, motion control, batch processing, materialhandling, or other such industrial functions. Industrial controllers 118typically execute respective control programs to facilitate monitoringand control of industrial devices 120 making up the controlledindustrial assets or systems (e.g., industrial machines). One or moreindustrial controllers 118 may also comprise a soft controller executedon a personal computer, on a server blade, or other hardware platform,or on a cloud platform. Some hybrid devices may also combine controllerfunctionality with other functions (e.g., visualization). The controlprograms executed by industrial controllers 118 can comprise anyconceivable type of code used to process input signals read from theindustrial devices 120 and to control output signals generated by theindustrial controllers, including but not limited to ladder logic,sequential function charts, function block diagrams, structured text,C++, Python, Javascript, etc.

Industrial devices 120 may include input devices that provide datarelating to the controlled industrial systems to the industrialcontrollers 118, output devices that respond to control signalsgenerated by the industrial controllers 118 to control aspects of theindustrial systems, or devices that act as both input and outputdevices. Example input devices can include telemetry devices (e.g.,temperature sensors, flow meters, level sensors, pressure sensors, etc),manual operator control devices (e.g., push buttons, selector switches,etc.), safety monitoring devices (e.g., safety mats, safety pull cords,light curtains, etc.), and other such devices. Output devices mayinclude motor drives, pneumatic actuators, signaling devices, robotcontrol inputs, valves, and the like. Some industrial devices, such asindustrial device 120M, may operate autonomously on the plant network116 without being controlled by an industrial controller 118.

Industrial controllers 118 may communicatively interface with industrialdevices 120 over hardwired connections or over wired or wirelessnetworks. For example, industrial controllers 118 can be equipped withnative hardwired inputs and outputs that communicate with the industrialdevices 120 to effect control of the devices. The native controller I/Ocan include digital I/O that transmits and receives discrete voltagesignals to and from the field devices, or analog I/O that transmits andreceives analog voltage or current signals to and from the devices. Thecontroller I/O can communicate with a controller's processor over abackplane such that the digital and analog signals can be read into andcontrolled by the control programs. Industrial controllers 118 can alsocommunicate with industrial devices 120 over the plant network 116using, for example, a communication module or an integrated networkingport. Exemplary networks can include the Internet, intranets, Ethernet,EtherNet/IP, DeviceNet, ControlNet, Data Highway and Data Highway Plus(DH/DH+), Remote I/O, Fieldbus, Modbus, Profibus, wireless networks,serial protocols, and the like. The industrial controllers 118 can alsostore persisted data values that can be referenced by the controlprogram and used for control decisions, including but not limited tomeasured or calculated values representing operational states of acontrolled machine or process (e.g., tank levels, positions, alarms,etc.) or captured time series data that is collected during operation ofthe automation system (e.g., status information for multiple points intime, diagnostic occurrences, etc.). Similarly, some intelligentdevices—including but not limited to motor drives, instruments, orcondition monitoring modules—may store data values that are used forcontrol and/or to visualize states of operation. Such devices may alsocapture time-series data or events on a log for later retrieval andviewing.

Industrial automation systems often include one or more human-machineinterfaces (HMIs) 114 that allow plant personnel to view telemetry andstatus data associated with the automation systems, and to control someaspects of system operation. HMIs 114 may communicate with one or moreof the industrial controllers 118 over a plant network 116, and exchangedata with the industrial controllers to facilitate visualization ofinformation relating to the controlled industrial processes on one ormore pre-developed operator interface screens. HMIs 114 can also beconfigured to allow operators to submit data to specified data tags ormemory addresses of the industrial controllers 118, thereby providing ameans for operators to issue commands to the controlled systems (e.g.,cycle start commands, device actuation commands, etc.), to modifysetpoint values, etc. HMIs 114 can generate one or more display screensthrough which the operator interacts with the industrial controllers118, and thereby with the controlled processes and/or systems. Exampledisplay screens can visualize present states of industrial systems ortheir associated devices using graphical representations of theprocesses that display metered or calculated values, employ color orposition animations based on state, render alarm notifications, oremploy other such techniques for presenting relevant data to theoperator. Data presented in this manner is read from industrialcontrollers 118 by HMIs 114 and presented on one or more of the displayscreens according to display formats chosen by the HMI developer. HMIsmay comprise fixed location or mobile devices with either user-installedor pre-installed operating systems, and either user-installed orpre-installed graphical application software.

Some industrial environments may also include other systems or devicesrelating to specific aspects of the controlled industrial systems. Thesemay include, for example, one or more data historians 110 that aggregateand store production information collected from the industrialcontrollers 118 and other industrial devices.

Industrial devices 120, industrial controllers 118, HMIs 114, associatedcontrolled industrial assets, and other plant-floor systems such as datahistorians 110, vision systems, and other such systems operate on theoperational technology (OT) level of the industrial environment. Higherlevel analytic and reporting systems may operate at the higherenterprise level of the industrial environment in the informationtechnology (IT) domain; e.g., on an office network 108 or on a cloudplatform 122. Such higher level systems can include, for example,enterprise resource planning (ERP) systems 104 that integrate andcollectively manage high-level business operations, such as finance,sales, order management, marketing, human resources, or other suchbusiness functions. Manufacturing Execution Systems (MES) 102 canmonitor and manage control operations on the control level givenhigher-level business considerations. Reporting systems 106 can collectoperational data from industrial devices on the plant floor and generatedaily or shift reports that summarize operational statistics of thecontrolled industrial assets.

OT level systems can be disparate and complex, and may integrate withmany physical devices. This challenging environment, together withdomain-specific programming and development languages, can makedevelopment of control systems on the OT level difficult, resulting inlong development cycles in which new control system designs aredeveloped, tested, and finally deployed. Moreover, given the generallack of current virtualization and simulation capabilities, industrialautomation systems must be purchased, programmed, and installed in thephysical operating environment before realistic testing or optimizationcan begin. This workflow often results in project delays or costoverruns. Moreover, the inherent complexity and custom nature ofinstalled industrial monitoring and control systems can make itdifficult for owners of industrial assets—e.g., plant owners orindustrial enterprise entities—to manage their OT-level systems and toprotect their proprietary intellectual property from catastrophicfailures or cyber-attacks.

To address these and other issues, one or more embodiments describedherein provide a cloud-based Industrial Development Hub (IDH) thatsupports development and testing capabilities for industrial customersthat are easy to use and offered as a service. The IDH comprises anenhanced storage platform and associated design tools—collectivelyreferred to as the Vault—which serves as a repository on which customerscan store control project code, device configurations, and other digitalaspects of an industrial automation project. The IDH system canfacilitate easy discovery and management of digital content associatedwith control systems, and can be used for system backup and restore,code conversion, and version management.

FIG. 2 is a block diagram of an example industrial development hub (IDH)repository system 202 according to one or more embodiments of thisdisclosure. Aspects of the systems, apparatuses, or processes explainedin this disclosure can constitute machine-executable components embodiedwithin machine(s), e.g., embodied in one or more computer-readablemediums (or media) associated with one or more machines. Suchcomponents, when executed by one or more machines, e.g., computer(s),computing device(s), automation device(s), virtual machine(s), etc., cancause the machine(s) to perform the operations described.

IDH repository system 202 can include a user interface component 204, aproject generation component 206, a project telemetry component 208, aproject analysis component 210, a project documentation component 212,an asset recovery component 214, an emulation component 216, asimulation component 218, one or more processors 224, and memory 228. Invarious embodiments, one or more of the user interface component 204,project generation component 206, project telemetry component 208,project analysis component 210, project documentation component 212,asset recovery component 214, emulation component 216, simulationcomponent 218, the one or more processors 224, and memory 226 can beelectrically and/or communicatively coupled to one another to performone or more of the functions of the IDH repository system 202. In someembodiments, components 204, 206, 208, 210, 212, 214, 216, and 218 cancomprise software instructions stored on memory 226 and executed byprocessor(s) 224. IDH repository system 202 may also interact with otherhardware and/or software components not depicted in FIG. 2. For example,processor(s) 224 may interact with one or more external user interfacedevices, such as a keyboard, a mouse, a display monitor, a touchscreen,or other such interface devices.

IDH repository system 202 can be implemented on a cloud platform as aset of cloud-based services to facilitate access by a diverse range ofusers having business or technical relationships, including industrialequipment owners (e.g., industrial enterprise entities or plant owners),equipment vendors, original equipment manufacturers (OEMs), systemintegrators, or other such user entities. The cloud platform on whichthe system 202 executes can be any infrastructure that allows sharedcomputing services to be accessed and utilized by cloud-capable devices.The cloud platform can be a public cloud accessible via the Internet bydevices having Internet connectivity and appropriate authorizations toutilize the IDH repository services. In some scenarios, the cloudplatform can be provided by a cloud provider as a platform-as-a-service(PaaS), and the IDH repository system 202 can reside and execute on thecloud platform as a cloud-based service. In some such configurations,access to the cloud platform and associated IDH repository services canbe provided to customers as a subscription service by an owner of theIDH repository system 202. Alternatively, the cloud platform can be aprivate cloud operated internally by the industrial enterprise (theowner of the plant facility). An example private cloud platform cancomprise a set of servers hosting the IDH repository system 202 andresiding on a corporate network protected by a firewall.

User interface component 204 can be configured to receive user input andto render output to the user in any suitable format (e.g., visual,audio, tactile, etc.). In some embodiments, user interface component 204can be configured to communicatively interface with a client device(e.g., a laptop computer, tablet computer, smart phone, etc.) that iscommunicatively connected to the IDH repository system 202 (e.g., via ahardwired or wireless connection). The user interface component 204 canthen serve an IDH interface environment to the client device, throughwhich the system 202 receives user input data and renders output data.In other embodiments, user interface component 204 can be configured togenerate and serve suitable interface screens to the client device(e.g., program development screens, project submission screens, analysisresult screens, etc.), and exchange data via these interface screens.Input data that can be received via various embodiments of userinterface component 204 can include, but is not limited to, programmingcode (including industrial control programming, such as ladder logicprogramming), device configuration data, engineering drawings, HMIapplications, or other such input. Output data rendered by variousembodiments of user interface component 204 can include program code,programming feedback (e.g., error and highlighting, coding suggestions,etc.), control project telemetry and recommendations, project testingresults, etc.

Project generation component 206 can be configured to create a controlsystem project comprising one or more project files based on designinput received via the user interface component 204, as well asindustrial knowledge, predefined code modules, and asset modelsmaintained by the IDH repository system 202. The control system projectcan comprise one or more of industrial control code (e.g., ladder logic,structured text, function block diagrams, etc.), HMI applicationscomprising one or more HMI interface screen definitions, deviceconfiguration files, or other such project files.

Project telemetry component 208 can be configured to analyze anindustrial control project submitted by a user and generate projecttelemetry, or statistical information, for the submitted project basedon the analysis. Example project telemetry data that can be generated bythe project telemetry component 208 can include, but is not limited to,an inventory of devices used in the project, information regarding howthe devices are being used, reports indicating how close to hardware orsoftware capacity limitations the devices or associated software will beoperating, how much memory or energy is expected to be consumed by theproject during runtime, or other such statistics.

Project analysis component 210 is configured to analyze the projecttelemetry data generated by the project telemetry component 208 andgenerate design recommendations or warnings based on this analysis.Project analysis component 210 can also generate device or equipmentusage statistics inferred from multiple projects submitted by multipleend customers for use by equipment vendors or OEMs.

Project documentation component 212 can be configured to generate avariety of project hand-off or validation documents based on analysis ofthe control system project, including but not limited to approvaldocuments, safety validation checklists, I/O checkout documents, auditdocumentation, or other such documents. Asset recovery component 214 canbe configured to collect and archive backups of control project filesand device configurations, and deploy these archived project files asneeded for disaster recovery or remote deployment purposes. Emulationcomponent 216 can be configured to emulate execution of an industrialcontrol project being testing on a virtualized (or emulated) industrialcontroller. Simulation component 218 can be configured to simulateoperation of a virtualized model of an industrial automation systemunder control of an industrial control project being emulated.

The one or more processors 224 can perform one or more of the functionsdescribed herein with reference to the systems and/or methods disclosed.Memory 226 can be a computer-readable storage medium storingcomputer-executable instructions and/or information for performing thefunctions described herein with reference to the systems and/or methodsdisclosed.

FIG. 3 is a diagram illustrating a generalized architecture of the IDHrepository system 202 according to one or more embodiments. As notedabove, IDH repository system 202 can execute on a cloud platform as aset of cloud-based storage, analysis, and project editing services. Aclient device 302 (e.g., a laptop computer, tablet computer, desktopcomputer, mobile device, wearable AR/VR appliance, etc.) can access therepository system's project development and analysis tools and leveragethese tools to either upload or create a control project for anautomation system being developed. To this end, the system's userinterface component 204 can remotely serve an IDH client 304 to theclient device 302. The IDH client 304 comprises a number of interfacedisplays that serve as an interface to the system 202.

Using the tools offered by the repository system 202, the user cansubmit a control project 306 to the repository system 202. In general, acontrol project 306 comprises digital data or files that, when executedon corresponding industrial devices deployed within an industrialenvironment, facilitate monitoring and control of an automation systemor industrial process. Control project 306 can comprise control codeintended for execution on an industrial controller (e.g., ladder logic,sequential function charts, structured text, function block diagrams,etc.), device configuration data (e.g., industrial controllerconfiguration files, motor drive configuration files, etc.),visualization applications (e.g., HMI applications, AR/VR content,etc.), or other such control project data. In some scenarios, controlcode 306 may also comprise engineering documentation for its associatedautomation system, including engineering drawings (e.g., CAD files),support documents, maintenance plans, or other such documentation. Insome scenarios in which the design tools offered by the IDH repositorysystem 202 are used to perform project development, control project 306can be submitted as ongoing project development input; e.g., as controlcode submitted to the repository system 202 as a designer is writing thecode. Alternatively, users can submit completed control projects to therepository for storage, analysis, and feedback. Both scenarios will bedescribed in more detail herein.

In addition to serving as a cloud-based storage for submitted controlproject 306, repository system 202 applies a variety of analytics on thesubmitted control project 306, and generates project recommendations 308for improving aspect of the submitted control project. This analysis canbe based on customer-specific and vendor-specific information containedin a customer repository 324 and a vendor repository 326 maintained onthe repository system 202, as well as general industrial expertisestored in a knowledgebase 328.

Repository system 202 can maintain multiple customer repositories 324designated for respective different end user entities (e.g., equipmentor plant owners, industrial enterprises, etc.). Owners of industrialassets can submit and archive project versions 310 in their designatedcustomer repositories 324. Users can also define customized plantstandards 314, which can be stored in the customer repository 324 andapplied to submitted control projects to ensure that the projects complywith the defined standards. Customer repository 324 can also storedigital asset models 312 corresponding to industrial assets in use atthe customer facility. These asset models 312 can be used for a varietyof purposes, including but not limited to digital simulations of thesubmitted control project.

The repository system 202 can also analyze control project 306 based onvendor-specific data submitted by equipment or device vendors and storedon one or more vendor repositories 326. Similar to customer repository324, repository system 202 can maintain multiple vendor repositories 326assigned to respective different equipment vendors or OEMs. Vendors cansubmit device profiles 316 or other types of digital models of theirequipment or devices for storage in their designated vendor repository326. These device profiles 316 can be used in connection with building adigital twin of a customer's automation system or plant environment, orto compare a customer's usage of their equipment with defined equipmentcapacities. Vendors can also submit and store applications 318 or codesegments that can be executed in connection with operation of theirequipment (e.g., control logic, HMI interface displays, reporting tools,etc.).

The submitted control project 306 can also be analyzed in view of otherarchived projects 320 submitted by other customers and deemed similar tothe submitted project. This analysis may be useful for identifyingportions of the submitted control project 306—e.g., code used to programa particular type of industrial machine or procedure—that deviate frommore common approaches used by other designers. Knowledgebase 328 canalso store a number of industry-specific standards definitions againstwhich the submitted control project 306 can be checked. Other types ofinformation can be stored and managed by the repository system in thevarious storage designations and used to analyze and optimize submittedcontrol project data, as will be described herein.

As noted above, control project 306 can be submitted as one or morecompleted project files for a given industrial control project to bestored and analyzed, or, if the repository system's native projectdevelopment tools are being used to create a new project, may besubmitted as design input during development of the project. FIG. 4 is adiagram illustrating example data flows associated with creation of anew control project 306 for an automation system being designed usingrepository system 202 according to one or more embodiments. In thisexample, client device 302 accesses the repository system's projectdevelopment tools and leverages these tools to create a control project302 for an automation system being developed. Control project 302 maycomprise one or more of industrial controller code, (e.g., controllogic, structured text, sequential function charts, etc.), deviceconfiguration files or parameter settings, HMI applications defining HMIscreens or AR/VR visualizations for visualizing the automation system'soperation, or other such aspects of a control project.

Accordingly, to facilitate project development, user interface component204 can serve development interface displays to the client device 302that allow a user to submit design input 404 to the repository system202 in various supported formats, including but not limited to controlprogramming for execution on an industrial controller, deviceconfiguration settings to be downloaded to respective industrial devices(e.g., motor drives, sensors, industrial controllers, etc.) tofacilitate configuration of those devices, HMI screen development data,or other such design input 404. Based on this design input 404, projectgeneration component 206 generates a control project 306 comprising oneor more of compiled controller code, device configuration data, HMIapplication files, or other such executable control project data thatcan be deployed and executed on the appropriate industrial devices tocarry out the programmed control functions.

In some embodiments, the repository system 202 can assist the developerin devising a hybrid project development approach, such that designfunctions are split between a local workstation and the cloud-baseddesign services. In this regard, the repository system 202 can assistthe designer to delineate which portions of project development areexecuted locally and which portions are executed on the cloud platform.

Also, during development of the control project 306, project generationcomponent 206 can generate design feedback 406 intended to assist thedeveloper in connection with developing and optimizing the controlproject 306, and this design feedback 406 can be rendered by the userinterface component 204 as real-time feedback to the designer. Thisdesign feedback 406 can be generated based on the analysis of the designinput 404 itself, as well as information stored in the customerrepository 324, vendor repository 326, and knowledgebase 328.

For example, as the designer is entering, as design input 404, controlcode to be compiled and executed on an industrial controller, projectgeneration component 206 can perform code analysis on the code andprovide recommendations, notifications, or predictions based on theanalysis relative to a variety of code or project quality metrics. Thisanalysis can include determining whether the control code conforms tothe engineering standards and practices used at the plant facility forwhich the code is being developed. To aid in this analysis, engineers atthe plant facility can submit control code standards definitionsdefining the coding standards that all control code is expected toadhere to before being permitted to execute within the plant facility.These coding standards can be stored in the customer's repository 324 asplant standards 314, and can be referenced by the project generationcomponent 206 as the designer submits design input 404 to determinewhether the submitted control code is in conformance with plantstandards.

Plant standards 314 can define coding standards both in terms ofpreferred control behaviors (e.g., preferred control sequences to beused or interlocks that must be recognized when carrying out aparticular type of control action, preferred maximum or minimum controlsetpoints for particular machine operations, etc.) as well as in termsof preferred code formatting. Plant standards 314 may also definepreferred parameters or configurations for particular types of devices(e.g., motor drives, network infrastructure devices, etc.), and projectgeneration component 206 can monitor the submitted design input 404during development to ensure that any device configurations submitted bythe designer conform to the defined standards. Upon determining, basedon this assessment, that the designer has entered a non-compliant deviceconfiguration, project generation component 206 can generate designfeedback notifying the user of the deviation and indicating theallowable configuration parameters.

Plant standards 314 may also include project-specific standards,including functional specifications or safety validation requirements.Project generation component 206 can monitor the design input 404 withreference to the functional project requirements defined by the plantstandards 314 and, upon determining that any portion of the submitteddesign input 404 deviates from the defined functional specifications orsafety validation requirements, generate design feedback notifying theuser of the deviation and offering recommendations as to how the deviantportion of the control project can be brought within compliance. Plantstandards 314 can define functional specifications in terms ofmanufacturing functions to be carried out, preferred equipment vendors,equipment to be used, product output requirements, energy consumptionrequirements, network utilization requirements, or other suchspecifications. Depending on the functional specifications set forth bythe plant standards 314, project generation component 206 can inferrelevant properties of the control project based on the design input 404and notify the user if any aspect of the project deviates from thesestandards. For example, if the functional specification dictates thatonly motor drives from an indicated preferred vendor are to be used forthe new installation, project generation component 206 may infer fromthe design input 404 (e.g., from the I/O configuration of an industrialcontroller, or from device configuration data included in the designinput 404) that devices from a non-approved vendor are being included inthe control project design, and notify the user that other devices froman approved vendor must be substituted.

In some embodiments, project generation component 206 can also comparecontrol code submitted as part of the design input 404 with previouslysubmitted control code included in archived project versions 310 for thesame control project or different control projects developed by the samecustomer. Based on analysis of other control code submitted by thecustomer and archived in the customer repository 324, project generationcomponent 206 can learn or infer typical coding styles or designapproaches used by that customer. This can include, for example, codeindentation preferences, preferences regarding the use of callstatements, rung commenting standards, variable or I/O naming standards,or other such preferred programming characteristics. In addition tocontrol coding standards, the project generation component 206 can alsoidentify the customer's preferred manner of programming certain controloperations. For example, project generation component 206 may identify,based on analysis of archived project versions 310, that the customeruses a particular control sequence in order to move material from asource container to a tank, or that the customer typically associates aparticular control operation with a set of interlocks that must besatisfied before the control operation can be performed.

Based on these learned customer programming preferences, the projectgeneration component 206 can identify whether the control programmingbeing submitted as part of design input 404 deviates from either theplant's preferred coding practices or the plant's preferred manner ofcontrolling certain industrial operations based on comparison with theproject versions 310, and generate design feedback 406 notifying ofthese deviations and recommending alternative control coding that willbring the current project into conformity with previous designstrategies. This feedback 406 may include, for example, a recommendationto add one or more interlocks to the control programming for aparticular control operation, a recommendation to re-order a sequence ofoperations for control of a particular type of machine, a recommendationto rename a variable or an I/O point to conform with the plant'spreferred nomenclature, a recommendation to add or revise a rungcomment, a recommendation to change an indentation for a portion ofcontrol code, a recommendation to replace repeated instances of codewith a CALL statement, or other such feedback.

Project generation component 206 can also reference vendor-specificequipment or device data in one or more vendor repositories 326 topredict whether the user's submitted design input 404 will causeequipment integration or compatibility issues. This determination can bebased, for example, on device profiles 316 submitted by the equipmentvendor for access by the project generation component 206. Each deviceprofiles 316 may comprise digital specification data for a given device,and may also record known compatibility issues for the device. Usingthis information, project generation component 206 can assess thesubmitted design input 404 to determine whether any portion of thesubmitted control programming or device configurations will result in aperformance or integration issue given known limitations of one or moredevices. This assessment may also consider inferred interactions betweensets of devices that the user is designing for collaborative operation.For example, if the design input 404 suggests that the designer isintending to configure two non-compatible devices for collaborativeoperation (as determined based on known compatibility issues recorded inthe device profiles 316), project generation component 206 can generatedesign feedback 406 indicating the two non-compatible devices.

The analysis applied by the project generation component 206 can alsoidentify improper or non-optimal coding practices within submittedcontrol code. This determination can be based in part on preferredcoding practices defined in the standards definitions 322 maintained inthe repository system's knowledgebase 328. Coding concerns that can beidentified by the project generation component 206 can include, but arenot limited to, excessive levels of nesting, excessive repeated code,improper code indentations, etc. In response to detecting such codingissues within the user's submitted code, the project generationcomponent 206 can provide design feedback recommending alternativeprogramming approaches that would bring the control code intoconformance with preferred coding standards (e.g. a recommendation toemploy case statements to eliminate excessive ladder logic).

Project generation component 206 may also identify modifications orsubstitutions that can be made within the control project 306 that mayimprove memory or network utilization associated with execution of thecontrol project 306. This may include, for example, identifyingalternative control code programming—or making another modification tothe control project 306—that may reduce the processing load on anindustrial controller without changing the intended control functions.In another example, the project generation component 206 may determinethat utilizing a currently unused function of a device (e.g., anoperating mode or a configuration parameter setting), or substituting adevice currently used in the control project 306 with a different devicemodel, may reduce energy consumption or network bandwidth utilization.

To support enhanced development capabilities, some embodiments of IDHrepository system 202 can support control programming based on anobject-based data model rather than a tag-based architecture. Automationobjects can serve as the building block for this object-baseddevelopment architecture. FIG. 5 is a diagram illustrating severalexample automation object properties that can be leveraged by therepository system 202 in connection with building, deploying, andexecuting a control project 306. Automation objects 504 can be createdand augmented during design, integrated into larger data models, andconsumed during runtime. These automation objects 504 provide a commondata structure across the repository system 202 and can be stored in anobject library (e.g., part of memory 226) for reuse. The object librarycan store predefined automation objects 504 representing variousclassifications of real-world industrial assets 502, including but notlimited to pumps, tanks, values, motors, motor drives (e.g., variablefrequency drives), industrial robots, actuators (e.g., pneumatic orhydraulic actuators), or other such assets. Automation objects 504 canrepresent elements at substantially any level of an industrialenterprise, including individual devices, machines made up of manyindustrial devices and components (some of which may be associated withtheir own automation objects 504), and entire production lines orprocess control systems.

An automation object 504 for a given type of industrial asset can encodesuch aspects as 2D or 3D visualizations, alarms, control coding (e.g.,logic or other type of control programming), analytics, startupprocedures, testing protocols and scripts, validation procedures andreports, simulations, schematics, security protocols, and other suchproperties associated with the industrial asset 502 represented by theobject 504. Automation objects 504 can also be geotagged with locationinformation identifying the location of the associated asset. Duringruntime of the control project 306, the automation object 504corresponding to a given real-world asset 502 can also record status oroperational history data for the asset. In general, automation objects504 serve as programmatic representations of their correspondingindustrial assets 502, and can be incorporated into a control project306 as elements of control code, a 2D or 3D visualization, aknowledgebase or maintenance guidance system for the industrial assets,or other such aspects.

Some embodiments of project analysis component 210 can also predictnetwork traffic or load statistics based on the device configurationinformation obtained from analysis of the control project 306 andgenerate network configuration recommendations based on thesepredictions. This analysis can be based on a comparison of thecustomer's network configuration with known or recommended networkconfigurations. Project analysis component 210 may also generate anetwork risk report indicating risks of network failure as a result ofimplementing the proposed control design.

Completed control projects 306—either developed using the repositorysystem's project editing tools (as described above in connection withFIG. 4) or using separate control project development platforms (e.g.,ladder logic development platforms, HMI application developmentplatforms, device configuration applications, etc.)—can be submitted tothe repository system 202 for analysis, archival, or upgrade purposes,as depicted in FIG. 3. In this regard, the IDH repository system 202serves as a secure and intelligent industrial control project repositoryopen to any number of participating industrial customers, which offersboth secure archival of control projects 306 as well as analysis ofthese projects 306 for the purposes of generating projectrecommendations 308 intended to optimize the control design, or to guidethe designer to previously unknown and unused device features that, ifutilized, may improve performance of the control project.

To facilitate intelligent analysis of a submitted control project 306,IDH repository system 202 can include a project telemetry component 208that generates project telemetry data for a submitted control project306, which can offer insights into both the control project itself aswell as the equipment and device topology of the automation system forwhich the control project 306 is being designed. FIG. 6 is a diagramillustrating extraction of project telemetry data 602 from a controlproject 306 submitted to the repository system 202. Based on analysis ofthe control project 306 project telemetry component 208 can determine orinfer characteristics of the control project itself, informationregarding the devices or equipment that makes up automation system to bemonitored and controlled by the control projects 306, predictionsregarding performance or resource utilization of the controlled system,the control design's estimated impacts on device lifecycle for one ormore devices, or other such project metrics.

For example, based on analysis of an industrial controller programfile—which may include control code, I/O configuration data, andnetworking configuration data for the an industrial controller—theproject telemetry component 208 may identify input or output devicesconnected to the industrial controller (e.g., based on examination ofthe I/O configuration or the control code itself), and record aninventory of these devices in the project telemetry data 602. Similaranalysis can be used to determine I/O or control modules configured foruse, as well as information regarding how the controller's I/O is beingutilized. Project telemetry component 208 can also record inferredfunctional or topological relationships between any two or more of thedevices or equipment identified as being part of the automation system.Project telemetry component 208 can also estimate a total amount ofnetwork bandwidth or energy that the automation system is expected toconsume. To yield further insights into how the devices that make up thecontrol system are being used, project telemetry data 602 can alsorecord which subset of the available features of a device are currentlybeing used by the control project 306.

In addition to metrics for the automation system to be controlled, theproject telemetry component 208 can also estimate performance metricsfor the control code itself, such as an estimated amount of memory orprocessing power required to execute aspects of the control project 306.

In some cases, project telemetry component 208 can enhance the projecttelemetry data 602 generated for the control project 306 by referencingvendor-specific device information stored in device profiles 316 on thevendor repository 326. For example, the project telemetry component 208may identify, based on analysis of the control project 306, that aparticular device model (e.g., an I/O module, a network infrastructuredevice, a motor drive, a servo, an actuator, etc.) is being used as acomponent of the automation system. Based on identification of thisdevice, project telemetry component 208 can access the vendor repository326 corresponding to the vendor of the device, determine whether adevice profile is available for the device, and, if so, retrievefunctional specification data for the device from the device profile 316for inclusion in the project telemetry data 602. This functionalspecification data, which depends on the type of device, can includesuch information as the device's available I/O, available configurationparameters or functionalities, available memory or processing capacity,lifecycle information, response times, physical dimensions, rated power,networking capabilities, operational limitations (e.g., environmentalrequirements, such as ambient temperatures for which the device israted), or other such supplemental device information.

Once project telemetry data 602 has been extracted for the controlproject 306, the repository system's project analysis component 210 cangenerate recommendations or notifications relevant to the project designbased on analysis of this project telemetry as well as encoded industryexpertise. FIG. 7 is a diagram illustrating generation of projectrecommendations 702 based on analysis of the extracted project telemetrydata 602. By analyzing project telemetry data 602, project analysiscomponent 210 can ascertain how the customer's industrial hardware andsoftware assets are being used and generate recommendations ornotifications based on this assessment. This can include determiningwhether the proposed control project—either due to control sequencesdefined by the control programming or the configuration parameters setfor one or more industrial devices—will cause hardware or software usedin the control project to operate near or above their rated operatingthresholds. For example, based on the control project's I/O utilization,as recorded in the project telemetry data 602, as well as knowledge ofthe I/O capacity of devices used in the control project (which may bedetermined based on specification data for those devices as record indevice profiles 316), project analysis component 210 may generate anotification that the proposed control design will cause one or morecontrol devices (e.g., industrial controllers or I/O modules) to near orexceed its maximum I/O capacity. Based on this assessment, the projectanalysis component 210 may further recommend an alternative controldevice having a higher I/O capacity than that currently proposed in thecontrol project in order to increase the number of spare I/O points forfuture expansion.

Project analysis component 210 may also estimate a degree of deviceutilization over time based on analysis of the project telemetry data602 and cross-reference this information with lifecycle information forthe device recorded in the device's profile 316, and generate anotification indicating an expected life cycle or time-to-failure forthe device if used as proposed in the control project. If an equivalentdevice having a longer expected lifecycle is available, project analysiscomponent 210 may also generate a recommendation to replace thecurrently proposed device with the equivalent. Alternatively, theproject analysis component 210 may recommend a modification to thecontrol project that may extend the lifespan of the device (e.g., byreducing the operating frequency of the device without otherwiseimpacting the control outcomes).

In some embodiments, project analysis component 210 may also identifyunused features of a device which, if utilized, may improve one or moreoperating metrics of the control project. These may be features of thedevice (e.g., configuration parameters, latent functions that areinactive by default but can be activated or invoked, etc.) that areavailable but are unknown to the designer. In an example scenario,project analysis component 210 may discover available features of adevice based on the functional specifications recorded in the device'sprofile 316, and determine whether any unused features may be relevantto an aspect of the control project 306, or may improve a performancemetric for the control project 306. For example, the project analysiscomponent 210 may determine that invoking a currently unused operatingmode of a device may reduce the memory footprint or network bandwidthusage of the device, may improve the automation system's productthroughput, may reduce energy or material consumption of the project asa whole, may reduce product waste, or may unlock another unforeseenimprovement in the project's operation. If such possible designimprovements are identified, user interface component 204 can send anotification to the designer (or another user entity associated with thecustomer) recommending the design modification. In an example scenario,based on submitted device configuration files as part of control project306, project analysis component 210 may determine that an unused featureof a drive (e.g., regenerative braking) may reduce overall powerconsumption, and generate a notification identifying the drive andindicating the unused feature. The notification may also offer arecommendation regarding when, during the control sequence, the featureshould be invoked in order to obtain the predicted benefit.

Project analysis component 210 may also determine whether any aspect ofthe control project 306 deviates from industry or plant standards. Thiscan be based on a comparison between the project telemetry 602 andindustry standards defined in the standards definitions 322 (stored inknowledgebase 328) or in-house standards defined in the plant standards314 stored in the customer repository 324. In the case of industrystandards, the particular set of standards against which the controlproject 306 is compared may be a function of the industrial vertical(e.g., automotive, pharmaceutical, food and drug, oil and gas, etc.) inwhich the control project 306 will operate, since some types ofindustries may require adherence to a vertical-specific set of controlstandards or requirements. Accordingly, the knowledgebase 328 mayclassify standards definitions 322 according to industrial vertical,allowing project analysis component 210 to select an appropriate set ofstandards to be applied to the control project 306. Standardsdefinitions 322 may define such industry standards as a required amountof unused I/O that must be reserved as spare capacity, an emissions orenergy consumption requirement, a safety integrity level (SIL)requirement, interlocks or permissives that should be associated with agiven type of control operation (e.g., tying a “valve open” command tothe fill level of a tank, preventing a machine start command untilspecified safety interlocks are satisfied) or other such standards.

Example in-house standards that can be recorded in the customer's plantstandards 314 and applied to the control project 306 can include, butare not limited to, control coding standards (as described above inconnection with FIG. 4), preferred vendors whose devices are approvedfor use within the plant, safety interlocks or permissives to beassociated with certain control functions, or other such standards.

Project analysis component 210 may also perform any of the projectanalytics, and generate any of the design feedback 406, described aboveas being carried out by the project generation component 206. Someproject analysis results may also trigger expert support review, suchthat the project analysis component 210 initiates remote review of theproject, contingent on the designer's permission, by a technical supportentity.

Since the control project analysis carried out by the project telemetrycomponent 208 and project analysis component 210 can identify or inferdevices and networks that will be used by the control project 306,project analysis component 210 can also generate an inventory of thedevices or industrial assets used by the customer's project. Repositorysystem 202 can store this asset inventory in the customer repository 324associated with the owner of the control project 306. Moreover, if anyof the discovered devices or industrial assets have associated digitaldevice profiles 316 made available by the vendors of the assets andstored on the vendor repository 326, repository system 202 can retrievethese device profiles 316 from the vendor repository 326 and store theprofiles 316 in the customer repository as asset models 312corresponding to the devices. In this regard, the device profiles 316may represent generic digital representations of their representedassets, and the project analysis component 210 may convert these genericdevice profiles 316 to customized asset models 312 representing thecustomer's uniquely configured assets based on the project telemetrydata 602. A device profile 316 for a given industrial device (e.g., anindustrial controller, a motor drive, a safety device, etc.) can becustomized, for example, by applying the designer's particularconfiguration parameters for that device (as obtained from the projecttelemetry data 602) to the device profile 316 to yield the customizedasset model 312 for the device. These asset models 312 can be used asthe basis for a digital twin of the automation system, which can be usedto simulate and test the control project 306 as will be described inmore detail herein.

Results of the analysis performed on the project telemetry data 602 canalso be formatted and filtered for use by equipment providers (e.g.,equipment vendors, OEMs, etc.) who participate in the repository systemecosystem, and this information can be made available to equipmentproviders as equipment usage statistics 704. For example, for everyequipment vendor whose equipment is being used in the control project306, the project analysis component 210 can provide data to the vendorindicating which of their devices are being used, as well as whichfeatures of those devices are being used. This data can be provided tothe vendor in a manner that anonymizes the end customer and prevents thevendor from being able to view the customer's proprietary information(e.g., recipe data, production statistics, etc.). In general, therepository system 202 protects a customer's proprietary data whileaffording enough access to provide the services. The user interfacecomponent 204 can allow the user to easily control how proprietary datais exposed to or hidden from outside entities who are also participatingin the IDH platform.

For a given equipment provider, the user interface component 204 cancompile these device or equipment statistics from multiple controlprojects 306 submitted by multiple different customers and present thisaggregated equipment usage and feature utilization information in anysuitable presentation format. For example, information regarding whichof the equipment provider's devices or assets are being used can bepresented as numbers of each asset in use at customer sites, geographicbreakdowns indicating where the assets are being used, charts indicatingrelative popularities of the vendor's product line, etc. Similarpresentations can be used to convey which features (e.g., operatingmodes, configuration parameters, etc.) of each of the vendor's productsare being used, or how closely their products are being utilized totheir functional capacities, as determined from aggregated projecttelemetry data 602 collected from multiple end customers using thevendor's products. Equipment providers can use these statistics 704 tomake decisions regarding whether to discontinue a product due to lack ofpopularity; to identify potentially useful product features that arebeing underutilized by their customers and therefore should be moreheavily promoted; to decide whether to increase or decrease memory,processing, or I/O resources of certain products based on a degree towhich these resources are being used by the customers; or to make otherinformed decisions regarding product design and promotion.

While some equipment usage statistics 704 may be presented to theequipment providers in a manner that anonymizes the end customers (e.g.,for the purposes of global product usage analysis), selected other suchstatistics 704 may be presented on a per-customer basis based on serviceor licensing agreements between the equipment provider and theircustomer. For example, some equipment providers, such as OEMs, may offerthe use of their equipment as a subscription service in which thecustomer purchases a license for a specified degree of usage of theequipment (e.g., a specified number of operating cycles per month, alimited subset of available equipment features, etc.). In suchscenarios, project analysis component 210 may determine an estimatedfrequency of usage of the provider's equipment based on analysis of theproject telemetry data 602, and make this information available to theequipment provider for the purposes of license enforcement.

According to another type of analysis that can be applied to the projecttelemetry data 602, project analysis component 210 can compare thecontrol project 306 or its extracted project telemetry data 602 withsimilar archived projects 320 submitted by other end customers, andidentify aspects of the submitted control project 306 that deviatesignificantly from corresponding aspects of the similar archivedprojects 320. User interface component 204 can then render, as a projectrecommendation 702, a notification indicating the deviant aspects of thecontrol project 306 and recommending a project modification that wouldbring the control project 306 in line with common practice. In this way,the repository system 202 can leverage collective industry expertise orcommon practice to provide recommendations regarding best practicesrelative to a submitted control project. Aspects of the submittedcontrol project 306 that can be compared in this manner can include, butare not limited to, interlock designs for a given type of controloperation, device configuration parameters (e.g., motor drive settings,network infrastructure device settings, safety device settings, etc.),control setpoints, orders of operations or timings for a given type ofcontrol operation or sequence, or other such project aspects.

Some embodiments of the repository system 202 can also simulate one ormore aspects of the submitted control project 306 to predict whether thecontrol project 306 will yield a desired outcome relative to one or morecontrolled machines. This allows the control project 306 to bepre-tested prior to execution on a physical machine. FIG. 8 is a diagramillustrating simulation of a control project 306 by the IDH repositorysystem 202. In this example, the repository system's emulation component216 acts as an industrial controller emulator to execute controlprogramming defined as part of the control project 306 against digitaltwin 810 or other type of virtualization of the automation system forwhich the control project 306 is being developed and tested. In someembodiments, the simulation component 218, which builds and simulatesthe digital twin 810, can create the digital twin 810 based in part onthe asset models 312 representing industrial devices or assets that makeup the automation system. As noted above, these asset models 312 can bemaintained on the customer repository 324, and may comprise deviceprofiles 316 obtained from the vendor repository 326 and customizedbased on configuration data obtained from the project analysis. Usingthese asset models 312, and the functional and/or topologicalrelationships between the industrial assets represented by the assetmodels 312 as inferred from analysis of the control project 306,simulation component 218 can generate a digital twin 810 of theautomation system against which the control project 306 can be simulatedand tested.

Simulation component 218 can leverage automation and mechanicalcharacteristics modeled by the digital twin 810 to simulate variousaspects of a physical automation system to be monitored and regulated bythe control project 306. To this end, simulation component 218 canvirtually interface the control project 306 with the digital twin 810 tofacilitate exchange of simulated I/O data between the control project306 (e.g., control code included in the control project 306) and digitaltwin 810, thereby simulating real-world control. Simulation component218 generates digital and analog I/O values representing, for example,sensor outputs, metering outputs, or other plant data analogous to thedata expected to be generated by the physical system based on the staticand dynamic characteristics of the physical system modeled by thedigital twin 810. This simulated output data 804 is provided to theemulation component 216, which receives this data 804 as one or morevirtual physical inputs. Control project 306 processes these inputsaccording to the user-defined control code defined in the project 306and generates digital and/or analog controller output data 802 based onthe processing. This output data 802 represents the physical outputsthat would be generated by an industrial controller or other type ofcontrol device executing the control code and transmitted to thehardwired field devices comprising the automation system (e.g., PID loopcontrol outputs, solenoid energizing outputs, motor control outputs,actuator control outputs, robot control outputs, etc.). The controlleroutput data 802 is provided to the appropriate input points of thedigital twin 810, which updates the simulated output data 804accordingly.

In addition to generating simulated output data 804, simulationcomponent 218 can also generate asset response data 806 based onanalysis of the simulated data exchange and expected behaviors of themodeled industrial assets in response to the simulated controller outputdata 802. For example, based on the automation and mechanicalcharacteristics of the industrial assets modeled in the digital twin810, simulation component 218 can predict expected behaviors of themodeled industrial assets, as well as behaviors of products beingmanufactured by the assets, in response to the controller output data802, and convey this predicted behavior as asset response data 806.Example behaviors represented by asset response data 806 can include,but are not limited to, movement of product through the industrialassets (including speeds, accelerations, locations, lags, etc.), flowrates of fluids through the assets, expected energy consumption by theassets, an expected rate of degradation of mechanical components of theassets (based in part on coefficient of friction information defined inthe asset models 312), expected forces applied to respective componentsof the assets during operation, or other such behaviors.

User interface component 204 can generate and render simulation results808 on a client device based on performance results of the simulation.These simulation results 808 can include simulated operating statisticsfor the automation system (e.g., product throughput rates, expectedmachine downtime frequencies, energy consumption, network traffic,expected machine or device lifecycle, etc.). In some embodiments, assetresponse data 806 can be provided to the project analysis component 210,which can determine whether any of the simulated asset responses deviatefrom acceptable or expected ranges, which may be defined in thefunctional specifications stored on the customer repository 324. Basedon results of this assessment, user interface component 204 can notifythe user of any predicted deviations from the expected operating rangesand render recommendations regarding modifications to the controlproject 306 that may bring expected performance within definedtolerances.

At the end of a new design cycle, the repository system 202 can alsogenerate project handoff and validation documents for the new controlproject. FIG. 9 is a diagram illustrating generation of handoffdocumentation 902 by the IDH repository system 202. Based on analysis ofthe completed control project 306, the repository system's projectdocumentation component 212 can generate a variety of projectdocumentation 902, including but not limited to approval documents,safety validation checklists, I/O checkout documents, and audit trails.At least some of this documentation 902 can be generated based oninformation stored in the customer repository 324. For example, projectdocumentation component 212 may generate I/O checkout documents for thecontrol project based on knowledge of the devices connected to thecontrol system I/O—as determined from the control project 306—as well asinformation about these devices obtained from the asset models 312corresponding to these devices. Similarly, safety validation checklistscan be generated based on asset-specific safety requirements defined inthe asset models 312. Some documentation 902 may also be generated basedon in-house approval requirements defined in the plant standards 314.These approval requirements may specify, for example, the personnel whomust sign their approval for various aspects of the control project.

Some documentation 212 may also be generated based on vertical-specificsafety or auditing standards defined in the standards definitions 322 ofthe knowledgebase 328. In this regard, some industrial verticals mayrequire compliance with regulations dictating how electronic recordsrelating to engineering and operation of an automation system arecollected and stored, how electronic signatures are obtained for theautomation system, what types of documentation must be collected forauditing purposes, etc. For example, plant facilities operating withinthe food and drug industry are required to maintain records incompliance with Title 21 CFR Part 11. Accordingly, project documentationcomponent 212 can identify types of project documentation required forthe control project 306 based on the industrial vertical for which theproject 306 is designed and the standards definitions 322 defining thedocumentation requirements for that vertical.

In some embodiments, the IDH repository system 202 can also managedigital or electronic signatures that are tied to the validationchecklists generated by the project documentation component 212. FIG. 10is a diagram illustrating collection of digital signatures by therepository system 202 according to one or more embodiments. In thisexample, digital validation checklists 1008 has been delivered to clientdevices 1006 associated with personnel who are required to sign off onaspects of the control project 302. The validation checklists areinteractive, such that each user can submit a digital signature 1004 forrespective items on the validation checklist 1008 via interaction withthe checklist. At the repository system 202, the digital signatures 1004are received from the client devices, and project documentationcomponent 212 maintains a record of the received signatures 1004 assign-off tracking data 1002, which tracks which signatures 1004 havebeen received for each item on the validation checklist, and from whomthe signatures 1004 have been received. This sign-off tracking data 1002can subsequently be referenced for auditing purposes. In someembodiments, the repository system can be configured to deploycomponents of control project 306 (e.g., control code, HMI visualizationapplications, device configurations, etc.) to their corresponding fielddevices only after all necessary signatures 1004 indicating approval ofthose components have been received.

IDH repository system 202 can also be used to archive past and currentversions of the control project 306 and perform related version controland analysis functions. FIG. 11 is a diagram illustrating submission ofa new version of control project 306 for archival with older projectversions 310. In this example, the customer repository 324 archives pastand current versions of the control project 306 as project versions 310.New versions of the control project 306 may be the result ofmodification to the control code, device firmware upgrades, additions tothe control project 306 to accommodate new equipment, or other suchchanges to the control project. Archiving current and past versions ofthe control project 306 allows project development to be journaledwithin the repository system, and also allows any version of the controlproject 306 to be selected and deployed to the automation system as partof a disaster recovery procedure in the event that portions of thecontrol project executing on the plant floor are lost and must bereinstalled, or if a new version of the control project 306 is notperforming as required and a previous version must be re-deployed. Thesefunctions can be managed by the repository system's asset recoverycomponent 214.

In some embodiments, when a new version of control project 306 issubmitted to the IDH repository system 202, the asset recovery component214 can analyze the new version of the control project 306 with one ormore previous versions 310 stored in the customer repository 324 andidentify any potential new problems introduced in the new versionrelative to previous versions. Asset recovery component 214 may alsoapply customer-defined project analysis queries defined in the plantstandards to the new version of the control project 306, as well asgeneralized project analysis queries defined as part of standardsdefinitions 322 stored in the repository system's knowledgebase 328.These generalized and custom queries can be configured to identifyspecific design scenarios within the control project 306 that may leadto non-optimal control performance Asset recovery component 214 canrender results of these project analytics as recommendations 1102.

In some embodiments, if an upgrade to a software application used by thecontrol project 306 is available, customers may submit a current versionof their control project (e.g., v.X) for upgrade to the newest version(e.g., v.Y). Asset recovery component 214 can also be configured tomanage these upgrades. When a control project 306 to be upgraded isuploaded to the repository system 202 by a customer, asset recoverycomponent 214 can analyze the control project 306 and perform theupgrade, performing any file conversions necessary to perform thev.X-to-v.Y upgrade. As part of this upgrade, asset recovery component214 can also apply any of the project analytics discussed above (e.g.,analytics similar to that applied by the project analysis component 210)to the uploaded control project 306. Upon completion of the upgrade,asset recovery component 214 can provide the upgraded control projectfiles together with recommendations (e.g., project recommendations 702described above) for improving operation of the control system oroptimizing resource utilization by the control project 306 itself.

By allowing multiple versions of a control project to be archived in thecustomer repository 324 and deployed to the plant floor devices ondemand, the repository system's storage and deployment features canallow users to deploy different versions of the same control project atdifferent industrial facilities. This functionality can be useful tosystem integrators or other control solution providers who servemultiple customers having different sets of industrial assets on whichthe control project 306 will be executed, since different versions ofthe control project 306 may be necessary for execution at differentcustomer sites.

Asset recovery component 214 can also implement cybersecurity featuresthat verify an authenticity of a submitted control project 306 to ensurethat the project 306 was developed and submitted by a reliable source.This authentication can be based in part on program code similarity. Forexample, when a new version of a control project 306 is submitted, assetrecovery component 214 can compare this new version with one or moreprevious project versions 310 previously submitted to and archived bythe repository system 202. If this comparison yields a determinationthat the new version is drastically different from previous versions 310uploaded by the same customer entity, the asset recovery component 214can flag the newly submitted control project 305 and initiate deliveryof a security notification to trusted personnel associated with thecustomer requesting that the new version be reviewed and authorized. Insome embodiments, asset recovery component 214 may also preventdeployment of the new version of the control project unlessauthorization from a trusted person is received. Asset recoverycomponent 214 may also authentication new control projects 306 based onadherence to or deviation from the customer's known coding style andstandards, which can be recorded in the customer repository 324 as partof plant standards 314.

Some embodiments of the IDH repository system 202 can also offer “backupas a service” for industrial asset configuration files or project files.FIG. 12 is a diagram illustrating intelligent backup of deviceconfiguration data 1206 to the IDH repository system 202. In someembodiments, software agents on-premise at the customer facility canlook for supported industrial devices or assets (e.g., assets installedin control cabinets 1204) and initiate backups of the deviceconfiguration data 1206 installed on those devices. Device configurationdata 1206 can include control code, configuration parameter settings,HMI applications, or other such control project data. In someembodiments, these software agents can be deployed and managed by asmart gateway device 1202 that reside on the plant network 166 andserves as a gateway or edge device that connects the industrial assetson the plant floor with the IDH repository system 202. In suchembodiments, smart gateway device 1202 can deliver copies of deviceconfiguration data 1206 to the IDH repository system 202, and the assetrecovery component 214 can store a backup of the device configurationdata 1206 in the customer repository 324 as part of the stored projectversions 310 for that customer.

Project backups can also be configured to be version-driven, such thatthe asset recovery component 214 uploads and archives changes to thecontrol project in response to detecting a modification to the projecton the plant floor (e.g., when a plant engineer modifies the ladderlogic on an industrial controller via a direct connection to thecontroller). In still another scenario, backups for asset configurationfiles can be scheduled, such that the asset recovery component 214retrieves and archives the current device configurations at definedtimes or according to a defined backup frequency.

With backups of the control project archived in the customer repository324, device configurations to be restored from the last known backup inthe event of a disaster. FIG. 13 is a diagram illustrating an examplerestore process that can be initiated by through the IDH repositorysystem 202. In this example, an industrial environment includes one ormore industrial controllers 118, HMIs 114, motor drives 1306, serversrunning higher level applications (e.g., ERP, MES, etc.), and other suchindustrial assets. These industrial assets are connected to the plantnetwork 116 (e.g., a common industrial protocol network, an Ethernet/IPnetwork, etc.) that facilitates data exchange between industrial deviceson the plant floor. Plant network 116 may be a wired or a wirelessnetwork.

When a control project 306 is to be deployed during a restore operation,the project 306 can be commissioned to the plant facility via a secureconnection between the smart gateway device 1202 and the cloud platformon which the repository system 202 resides. Asset recovery component 214can translate the archived control project 306 to one or moreappropriate executable files—control program files 1302, visualizationapplications 1304, device configuration files 1308, system configurationfile, etc. —and deploy these files to the appropriate devices in theplant facility to facilitate deployment or restore of the controlproject.

This backup and restore architecture can also be used to upload systemconfigurations from one facility and deploy them at another facility, orto upload configurations from an OEM and deploy them to a customer site.As part of the deployment procedure, the asset recovery component 214can first poll the target devices on the plant floor to verify thatthose devices are capable of supporting and executing the controlproject files that are being deployed.

By affording a common storage and analysis platform on which multiplecustomers can upload and assess their control solutions, the IDHrepository system 202 can accelerate modern automation development bycreating an open ecosystem for engineers to share and reuse code fromprivate and public repositories, allowing them to easily manage andcollaborate with their own content and from others they trust toaccelerate core control development.

FIGS. 14-15 b illustrate various methodologies in accordance with one ormore embodiments of the subject application. While, for purposes ofsimplicity of explanation, the one or more methodologies shown hereinare shown and described as a series of acts, it is to be understood andappreciated that the subject innovation is not limited by the order ofacts, as some acts may, in accordance therewith, occur in a differentorder and/or concurrently with other acts from that shown and describedherein. For example, those skilled in the art will understand andappreciate that a methodology could alternatively be represented as aseries of interrelated states or events, such as in a state diagram.Moreover, not all illustrated acts may be required to implement amethodology in accordance with the innovation. Furthermore, interactiondiagram(s) may represent methodologies, or methods, in accordance withthe subject disclosure when disparate entities enact disparate portionsof the methodologies. Further yet, two or more of the disclosed examplemethods can be implemented in combination with each other, to accomplishone or more features or advantages described herein.

FIG. 14 illustrates an example methodology 1400 for providing real-timedesign feedback for an industrial control project during developmentusing a cloud-based IDH repository system. Initially, at 1402, designdata is received via interaction with a cloud-based IDH repositorysystem. The design data can specify control aspects of a control systemto be used to monitor and control an industrial automation system, andcan be received in the form of industrial control programming (e.g.,ladder logic, sequential function charts, scripted control code such asan industrial DSL, etc.), HMI screen development input, industrialdevice or equipment selections and configuration data (e.g., deviceconfiguration parameter values), or other such design input. In someembodiment, the design data can be submitted to the IDH repositorysystem via interaction with a control system development platform servedto a client device by the repository system, where the developmentplatform comprises development tools for programming industrial controlcode, designing HMI interface displays, setting device parameters, orother such design actions.

At 1404, during receipt of the design data—that is, as a user proceedsthrough control project development—the repository system monitors thedesign data in view of one or more of defined plant standards orindustry-specific design guidelines stored on the repository system.Plant standards can be uploaded to the repository system by engineers oradministrators at the plant facility and stored in a customer-specificrepository, and can define such engineering standards as preferredcontrol code formatting, orders in which certain control sequences areto be carried out, control interlocks that must be in place beforecertain control actions can be executed, permitted control setpointranges, preferred device operating ranges or configuration parameters,preferred network settings, or other such engineering standards andpreferences. The plant standards may also define standards specific tothe control project being developed, including functional specificationsor safety validation requirements.

Industry-specific guidelines can also be stored and maintained on therepository system, and may be categorized according to relevantindustrial verticals. These industry-specific guidelines may specify,for example, emissions or energy consumption requirements, requiredsafety integrity levels, industry-standard interlocks, or other suchstandards.

At 1406, a determination is made, based on the monitoring performed atstep 1404, whether a portion of the design data received at step 1402deviates rom the plant standards or design guidelines. These deviationsmay comprise, for example, non-conformity to approved control codingpractices, insufficient safety interlocking associated with a controloperation, device configuration settings that fall outside an approvedrange, or other such deviations. If no such deviations are detected (NOat step 1406), the methodology returns to step 1402 and steps 1402-1406repeat. Alternatively, if a deviation is detected (YES at step 1406),the methodology proceeds to step 1408, where the IDH repository systemrenders design feedback based on the deviation. The feedback can notifythe designer of the deviation, and offer recommendations for modifyingthe design in a manner that brings the design within the plant-specificand industry-specific guidelines.

FIG. 15a illustrates a first part of an example methodology 1500 a forperforming control project analytics on an uploaded control project andcollecting vendor-specific device usage statistics based on results ofthe analytics. Initially, at 1502, a control project is received at acloud-based IDH repository system. The control project can be uploadedby customer (e.g., authorized personnel at a plant facility at which thecontrol project operates) for archival or analysis purposes, orautomatically archived to the repository system as part of abackup-and-restore procedure. The control project comprises controlprogramming and device configuration data for programming andconfiguring an industrial control system at the plant facility.

At 1504, project telemetry data is extracted from the control project bythe repository system. This project telemetry data can comprise, forexample, an inventory of devices that make up the control system, I/Outilization of the devices, network resources (e.g., communicationbandwidth) utilized by the control system, predicted device lifecycleinformation, an expected frequency of operating cycles of one or more ofthe devices, an expected processing load on one or more of the devicesas a result of executing the control project, an expected amount ofdevice memory consumed as a result of executing the control project, asubset of available features of a device that are being utilized by thecontrol project, or other such telemetry.

At 1506, analysis is performed on the project telemetry data extractedat step 1504 in view of at least one of defined plant standards,industry-specific design guidelines, digital asset models, or similararchived control project stored on the repository system. For example,the submitted control project can be assessed for deviations from plantor industry-specific design standards and guidelines, as discussed instep 1406 in methodology 1400. The repository system can also comparethe control project with a subset of other archived control projectsthat perform similar control functions to that of the submitted project(e.g., projects designed to control similar machinery within similarindustries, or to otherwise perform similar control functions) todetermine whether portions of the control project design deviate frommore common design approaches for similar control functions.

The repository system can also access digital asset models representingdevices used in the control project (and identified in the telemetrydata) in order to determine how these devices are used relative to thedesign specifications and available features. For example, based oninformation maintained on device-specific asset models, the repositorysystem can determine what percentage of the device's available I/O iscurrently being used in the control project, what percentage of thedevice's available memory or processing capacity will be consumed by thecontrol project (e.g., as a result of executing the proposed controlcode), which of the device's available features are not being utilizedby the control project, or other such statistics.

At 1508, a determination is made as to whether the analysis performed atstep 1506 identifies an opportunity to improve a performance metric ofthe control project. If such an opportunity is identified (YES at step1508), the methodology proceeds to step 1510, where the repositorysystem renders recommendations for modifications to the control projectbased on results of the analysis. These can include, for example,recommendations for reducing the memory or processing utilization by oneor more devices of the control system, recommendations for altering thecontrol project in a manner that extends the expected lifecycle for adevice (e.g., by reducing the operating frequency of the device),indications of unused device features that may improve performance ifutilized, or other such recommendations.

The methodology then proceeds to the second part 1500 b illustrated inFIG. 15b . At 1512, a subset of the project telemetry data (extracted atstep 1504) relating to industrial devices or assets provided by aparticular equipment vendor is stored in a vendor repository associatedwith that vendor. This subset of telemetry data can include, forexample, which of the vendor's devices are being used by the controlproject, which available features of the devices are being used andwhich are unused, how closely the devices are being operated to theirmaximum operating constraints (e.g., in terms of memory, processingpower, speed, etc.), or other such information. At 1514, vendor-specificstatistics collected from the project telemetry data of multiplesubmitted control projects are aggregated by the repository system andstored in the vendor repository. These vendor-specific statistics relateto industrial assets that are offered by the vendor and in use atmultiple customer facilities that participate in the IDH repositoryplatform. At 1516, the repository system provides access to theaggregated vendor-specific statistics to entities associated with thevendor. These statistics can comprise, for example, the numbers of eachof the vendor's products that are deployed at customer locations, howthose products are being used in the field, which degree to whichfeatures of the vendor's products are being used, how closely thevendor's products are being operated to their engineering capacities,the geographic locations at which the vendor's respective products arebeing used, or other such statistics.

Embodiments, systems, and components described herein, as well ascontrol systems and automation environments in which various aspects setforth in the subject specification can be carried out, can includecomputer or network components such as servers, clients, programmablelogic controllers (PLCs), automation controllers, communicationsmodules, mobile computers, on-board computers for mobile vehicles,wireless components, control components and so forth which are capableof interacting across a network. Computers and servers include one ormore processors—electronic integrated circuits that perform logicoperations employing electric signals—configured to execute instructionsstored in media such as random access memory (RAM), read only memory(ROM), a hard drives, as well as removable memory devices, which caninclude memory sticks, memory cards, flash drives, external hard drives,and so on.

Similarly, the term PLC or automation controller as used herein caninclude functionality that can be shared across multiple components,systems, and/or networks. As an example, one or more PLCs or automationcontrollers can communicate and cooperate with various network devicesacross the network. This can include substantially any type of control,communications module, computer, Input/Output (I/O) device, sensor,actuator, and human machine interface (HMI) that communicate via thenetwork, which includes control, automation, and/or public networks. ThePLC or automation controller can also communicate to and control variousother devices such as standard or safety-rated I/O modules includinganalog, digital, programmed/intelligent I/O modules, other programmablecontrollers, communications modules, sensors, actuators, output devices,and the like.

The network can include public networks such as the internet, intranets,and automation networks such as control and information protocol (CIP)networks including DeviceNet, ControlNet, safety networks, andEthernet/IP. Other networks include Ethernet, DH/DH+, Remote I/O,Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols,Open Platform Communications Unified Architecture (OPC-UA), and soforth. In addition, the network devices can include variouspossibilities (hardware and/or software components). These includecomponents such as switches with virtual local area network (VLAN)capability, LANs, WANs, proxies, gateways, routers, firewalls, virtualprivate network (VPN) devices, servers, clients, computers,configuration tools, monitoring tools, and/or other devices.

In order to provide a context for the various aspects of the disclosedsubject matter, FIGS. 16 and 17 as well as the following discussion areintended to provide a brief, general description of a suitableenvironment in which the various aspects of the disclosed subject mattermay be implemented. While the embodiments have been described above inthe general context of computer-executable instructions that can run onone or more computers, those skilled in the art will recognize that theembodiments can be also implemented in combination with other programmodules and/or as a combination of hardware and software.

Generally, program modules include routines, programs, components, datastructures, etc., that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat the inventive methods can be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, minicomputers, mainframe computers, Internet of Things (IoT)devices, distributed computing systems, as well as personal computers,hand-held computing devices, microprocessor-based or programmableconsumer electronics, and the like, each of which can be operativelycoupled to one or more associated devices.

The illustrated embodiments herein can be also practiced in distributedcomputing environments where certain tasks are performed by remoteprocessing devices that are linked through a communications network. Ina distributed computing environment, program modules can be located inboth local and remote memory storage devices.

Computing devices typically include a variety of media, which caninclude computer-readable storage media, machine-readable storage media,and/or communications media, which two terms are used herein differentlyfrom one another as follows. Computer-readable storage media ormachine-readable storage media can be any available storage media thatcan be accessed by the computer and includes both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable storage media or machine-readablestorage media can be implemented in connection with any method ortechnology for storage of information such as computer-readable ormachine-readable instructions, program modules, structured data orunstructured data.

Computer-readable storage media can include, but are not limited to,random access memory (RAM), read only memory (ROM), electricallyerasable programmable read only memory (EEPROM), flash memory or othermemory technology, compact disk read only memory (CD-ROM), digitalversatile disk (DVD), Blu-ray disc (BD) or other optical disk storage,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, solid state drives or other solid statestorage devices, or other tangible and/or non-transitory media which canbe used to store desired information. In this regard, the terms“tangible” or “non-transitory” herein as applied to storage, memory orcomputer-readable media, are to be understood to exclude onlypropagating transitory signals per se as modifiers and do not relinquishrights to all standard storage, memory or computer-readable media thatare not only propagating transitory signals per se.

Computer-readable storage media can be accessed by one or more local orremote computing devices, e.g., via access requests, queries or otherdata retrieval protocols, for a variety of operations with respect tothe information stored by the medium.

Communications media typically embody computer-readable instructions,data structures, program modules or other structured or unstructureddata in a data signal such as a modulated data signal, e.g., a carrierwave or other transport mechanism, and includes any information deliveryor transport media. The term “modulated data signal” or signals refersto a signal that has one or more of its characteristics set or changedin such a manner as to encode information in one or more signals. By wayof example, and not limitation, communication media include wired media,such as a wired network or direct-wired connection, and wireless mediasuch as acoustic, RF, infrared and other wireless media.

With reference again to FIG. 16, the example environment 1600 forimplementing various embodiments of the aspects described hereinincludes a computer 1602, the computer 1602 including a processing unit1604, a system memory 1606 and a system bus 1608. The system bus 1608couples system components including, but not limited to, the systemmemory 1606 to the processing unit 1604. The processing unit 1604 can beany of various commercially available processors. Dual microprocessorsand other multi-processor architectures can also be employed as theprocessing unit 1604.

The system bus 1608 can be any of several types of bus structure thatcan further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. The system memory 1606includes ROM 1610 and RAM 1612. A basic input/output system (BIOS) canbe stored in a non-volatile memory such as ROM, erasable programmableread only memory (EPROM), EEPROM, which BIOS contains the basic routinesthat help to transfer information between elements within the computer1602, such as during startup. The RAM 1612 can also include a high-speedRAM such as static RAM for caching data.

The computer 1602 further includes an internal hard disk drive (HDD)1614 (e.g., EIDE, SATA), one or more external storage devices 1616(e.g., a magnetic floppy disk drive (FDD) 1616, a memory stick or flashdrive reader, a memory card reader, etc.) and an optical disk drive 1620(e.g., which can read or write from a CD-ROM disc, a DVD, a BD, etc.).While the internal HDD 1614 is illustrated as located within thecomputer 1602, the internal HDD 1614 can also be configured for externaluse in a suitable chassis (not shown). Additionally, while not shown inenvironment 1600, a solid state drive (SSD) could be used in additionto, or in place of, an HDD 1614. The HDD 1614, external storagedevice(s) 1616 and optical disk drive 1620 can be connected to thesystem bus 1608 by an HDD interface 1624, an external storage interface1626 and an optical drive interface 1628, respectively. The interface1624 for external drive implementations can include at least one or bothof Universal Serial Bus (USB) and Institute of Electrical andElectronics Engineers (IEEE) 1394 interface technologies. Other externaldrive connection technologies are within contemplation of theembodiments described herein.

The drives and their associated computer-readable storage media providenonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For the computer 1602, the drives andstorage media accommodate the storage of any data in a suitable digitalformat. Although the description of computer-readable storage mediaabove refers to respective types of storage devices, it should beappreciated by those skilled in the art that other types of storagemedia which are readable by a computer, whether presently existing ordeveloped in the future, could also be used in the example operatingenvironment, and further, that any such storage media can containcomputer-executable instructions for performing the methods describedherein.

A number of program modules can be stored in the drives and RAM 1612,including an operating system 1630, one or more application programs1632, other program modules 1634 and program data 1636. All or portionsof the operating system, applications, modules, and/or data can also becached in the RAM 1612. The systems and methods described herein can beimplemented utilizing various commercially available operating systemsor combinations of operating systems.

Computer 1602 can optionally comprise emulation technologies. Forexample, a hypervisor (not shown) or other intermediary can emulate ahardware environment for operating system 1630, and the emulatedhardware can optionally be different from the hardware illustrated inFIG. 16. In such an embodiment, operating system 1630 can comprise onevirtual machine (VM) of multiple VMs hosted at computer 1602.Furthermore, operating system 1630 can provide runtime environments,such as the Java runtime environment or the .NET framework, forapplication programs 1632. Runtime environments are consistent executionenvironments that allow application programs 1632 to run on anyoperating system that includes the runtime environment. Similarly,operating system 1630 can support containers, and application programs1632 can be in the form of containers, which are lightweight,standalone, executable packages of software that include, e.g., code,runtime, system tools, system libraries and settings for an application.

Further, computer 1602 can be enable with a security module, such as atrusted processing module (TPM). For instance with a TPM, bootcomponents hash next in time boot components, and wait for a match ofresults to secured values, before loading a next boot component. Thisprocess can take place at any layer in the code execution stack ofcomputer 1602, e.g., applied at the application execution level or atthe operating system (OS) kernel level, thereby enabling security at anylevel of code execution.

A user can enter commands and information into the computer 1602 throughone or more wired/wireless input devices, e.g., a keyboard 1638, a touchscreen 1640, and a pointing device, such as a mouse 1642. Other inputdevices (not shown) can include a microphone, an infrared (IR) remotecontrol, a radio frequency (RF) remote control, or other remote control,a joystick, a virtual reality controller and/or virtual reality headset,a game pad, a stylus pen, an image input device, e.g., camera(s), agesture sensor input device, a vision movement sensor input device, anemotion or facial detection device, a biometric input device, e.g.,fingerprint or iris scanner, or the like. These and other input devicesare often connected to the processing unit 1604 through an input deviceinterface 1644 that can be coupled to the system bus 1608, but can beconnected by other interfaces, such as a parallel port, an IEEE 1394serial port, a game port, a USB port, an IR interface, a BLUETOOTH®interface, etc.

A monitor 1644 or other type of display device can be also connected tothe system bus 1608 via an interface, such as a video adapter 1646. Inaddition to the monitor 1644, a computer typically includes otherperipheral output devices (not shown), such as speakers, printers, etc.

The computer 1602 can operate in a networked environment using logicalconnections via wired and/or wireless communications to one or moreremote computers, such as a remote computer(s) 1648. The remotecomputer(s) 1648 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computer1602, although, for purposes of brevity, only a memory/storage device1650 is illustrated. The logical connections depicted includewired/wireless connectivity to a local area network (LAN) 1652 and/orlarger networks, e.g., a wide area network (WAN) 1654. Such LAN and WANnetworking environments are commonplace in offices and companies, andfacilitate enterprise-wide computer networks, such as intranets, all ofwhich can connect to a global communications network, e.g., theInternet.

When used in a LAN networking environment, the computer 1602 can beconnected to the local network 1652 through a wired and/or wirelesscommunication network interface or adapter 1656. The adapter 1656 canfacilitate wired or wireless communication to the LAN 1652, which canalso include a wireless access point (AP) disposed thereon forcommunicating with the adapter 1656 in a wireless mode.

When used in a WAN networking environment, the computer 1602 can includea modem 1658 or can be connected to a communications server on the WAN1654 via other means for establishing communications over the WAN 1654,such as by way of the Internet. The modem 1658, which can be internal orexternal and a wired or wireless device, can be connected to the systembus 1608 via the input device interface 1642. In a networkedenvironment, program modules depicted relative to the computer 1602 orportions thereof, can be stored in the remote memory/storage device1650. It will be appreciated that the network connections shown areexample and other means of establishing a communications link betweenthe computers can be used.

When used in either a LAN or WAN networking environment, the computer1602 can access cloud storage systems or other network-based storagesystems in addition to, or in place of, external storage devices 1616 asdescribed above. Generally, a connection between the computer 1602 and acloud storage system can be established over a LAN 1652 or WAN 1654e.g., by the adapter 1656 or modem 1658, respectively. Upon connectingthe computer 1602 to an associated cloud storage system, the externalstorage interface 1626 can, with the aid of the adapter 1656 and/ormodem 1658, manage storage provided by the cloud storage system as itwould other types of external storage. For instance, the externalstorage interface 1626 can be configured to provide access to cloudstorage sources as if those sources were physically connected to thecomputer 1602.

The computer 1602 can be operable to communicate with any wirelessdevices or entities operatively disposed in wireless communication,e.g., a printer, scanner, desktop and/or portable computer, portabledata assistant, communications satellite, any piece of equipment orlocation associated with a wirelessly detectable tag (e.g., a kiosk,news stand, store shelf, etc.), and telephone. This can include WirelessFidelity (Wi-Fi) and BLUETOOTH® wireless technologies. Thus, thecommunication can be a predefined structure as with a conventionalnetwork or simply an ad hoc communication between at least two devices.

FIG. 17 is a schematic block diagram of a sample computing environment1700 with which the disclosed subject matter can interact. The samplecomputing environment 1700 includes one or more client(s) 1702. Theclient(s) 1702 can be hardware and/or software (e.g., threads,processes, computing devices). The sample computing environment 1700also includes one or more server(s) 1704. The server(s) 1704 can also behardware and/or software (e.g., threads, processes, computing devices).The servers 1704 can house threads to perform transformations byemploying one or more embodiments as described herein, for example. Onepossible communication between a client 1702 and servers 1704 can be inthe form of a data packet adapted to be transmitted between two or morecomputer processes. The sample computing environment 1700 includes acommunication framework 1706 that can be employed to facilitatecommunications between the client(s) 1702 and the server(s) 1704. Theclient(s) 1702 are operably connected to one or more client datastore(s) 1708 that can be employed to store information local to theclient(s) 1702. Similarly, the server(s) 1704 are operably connected toone or more server data store(s) 1710 that can be employed to storeinformation local to the servers 1704.

What has been described above includes examples of the subjectinnovation. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe disclosed subject matter, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the subjectinnovation are possible. Accordingly, the disclosed subject matter isintended to embrace all such alterations, modifications, and variationsthat fall within the spirit and scope of the appended claims.

In particular and in regard to the various functions performed by theabove described components, devices, circuits, systems and the like, theterms (including a reference to a “means”) used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., a functional equivalent), even though not structurallyequivalent to the disclosed structure, which performs the function inthe herein illustrated exemplary aspects of the disclosed subjectmatter. In this regard, it will also be recognized that the disclosedsubject matter includes a system as well as a computer-readable mediumhaving computer-executable instructions for performing the acts and/orevents of the various methods of the disclosed subject matter.

In addition, while a particular feature of the disclosed subject mattermay have been disclosed with respect to only one of severalimplementations, such feature may be combined with one or more otherfeatures of the other implementations as may be desired and advantageousfor any given or particular application. Furthermore, to the extent thatthe terms “includes,” and “including” and variants thereof are used ineither the detailed description or the claims, these terms are intendedto be inclusive in a manner similar to the term “comprising.”

In this application, the word “exemplary” is used to mean serving as anexample, instance, or illustration. Any aspect or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Rather, use of the wordexemplary is intended to present concepts in a concrete fashion.

Various aspects or features described herein may be implemented as amethod, apparatus, or article of manufacture using standard programmingand/or engineering techniques. The term “article of manufacture” as usedherein is intended to encompass a computer program accessible from anycomputer-readable device, carrier, or media. For example, computerreadable media can include but are not limited to magnetic storagedevices (e.g., hard disk, floppy disk, magnetic strips . . . ), opticaldisks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ],smart cards, and flash memory devices (e.g., card, stick, key drive . .. ).

What is claimed is:
 1. A system for analyzing industrial controlprojects, comprising: a memory that stores executable components; and aprocessor, operatively coupled to the memory, that executes theexecutable components, the executable components comprising: a userinterface component configured to receive, from a client device via acloud platform, an industrial control project comprising at leastcontrol programming and device configuration data that, in response toexecution on one or more industrial devices, facilitate monitoring andcontrol of an industrial automation system; a project telemetrycomponent configured to generate project telemetry data based on a firstanalysis of the industrial control project, the project telemetry datadefining characteristics of the one or more industrial devices andpredicted operating characteristics of the industrial control projectinferred based on the first analysis; and a project analysis componentconfigured to perform a second analysis on the project telemetry dataand to generate, based on a result of the second analysis, arecommendation for modifying the industrial control project in a mannerthat improves one or more of the predicted operating characteristics,wherein the user interface component is configured to render therecommendation on the client device.
 2. The system of claim 1, whereinthe project telemetry component is configured to determine, as a portionof the project telemetry data, an inventory of the one or moreindustrial devices used in the industrial control project, and determineother industrial assets included in the industrial automation systembased on analysis of device configuration data for the one or moreindustrial devices.
 3. The system of claim 1, wherein the system isconfigured to maintain multiple vendor-specific repositories that storedigital device profiles representing industrial assets provided byrespective different equipment vendors, the digital device profilesdefining functional specifications for the industrial assets, and theproject analysis component is configured to, in response to determiningthat a device profile, of the digital device profiles, corresponds to anindustrial device of the one or more industrial devices identified bythe project telemetry data, generate the recommendation based on acomparison of the project telemetry data with the device profile.
 4. Thesystem of claim 3, wherein the recommendation comprises at least one ofa recommended replacement or reconfiguration of the industrial device toreduce an amount of memory or processing resources consumed by thecontrol project, a recommended replacement or reconfiguration for theindustrial device to increase an I/O capacity for the control project, arecommendation to utilize a currently unused feature of the industrialdevice to improve a performance metric of the control project, or arecommended reconfiguration of the industrial control project toincrease an expected lifespan of the industrial device.
 5. The system ofclaim 3, wherein the industrial control project defines a controlsequence involving an industrial device represented by a device profileof the digital device profiles, and the project analysis component isconfigured to, in response to determining, based on analysis of thecontrol sequence and the device profile, that the control sequence willcause an operating capacity threshold of the industrial device to beexceeded, generate the recommendation to indicate a modification to theindustrial control project that increases an available operatingcapacity of the industrial device.
 6. The system of claim 3, wherein theproject analysis component is configured to identify, based on thecomparison of the project telemetry data with the device profile, thatthe industrial device supports a feature that is currently unused by theindustrial control project and that would improve a performance metricof the industrial control project, and the recommendation comprises arecommendation to modify the industrial control project to utilize theunused feature.
 7. The system of claim 1, wherein the project telemetrydata comprises at least one of an inventory of I/O modules or controlmodules used by the control project, identification of industrialequipment connected to the I/O modules, a functional relationshipbetween items of the industrial equipment or the one or more industrialdevices, an amount of available I/O utilized by the control project,estimated network bandwidth consumed by the control project, a usagefrequency of an industrial device of the one or more industrial devices,an estimated lifecycle for the industrial device, an estimatedtime-to-failure of the industrial device, an estimated amount of memoryconsumed by the industrial control project, an estimated amount ofenergy consumed by the industrial control project, or an estimatedamount of processing utilization by the control project.
 8. The systemof claim 1, wherein the second analysis comprises comparing the projecttelemetry data with at least one of plant-specific standards definitionsstored in a customer-specific repository or industry-specific standardsdefinitions stored in a knowledgebase, and the project analysiscomponent is configured to, in response to determining, based on aresult of the second analysis, that an aspect of the industrial controlproject deviates from at least one of the plant-specific standardsdefinitions or the industry-specific standards definitions, generate therecommendation to indicate a modification to the industrial controlproject that brings the aspect into compliance with the at least one ofthe plant-specific standards definitions or the industry-specificstandards definitions.
 9. The system of claim 8, wherein theplant-specific standards definitions or the industry-specific standardsdefinitions define at least one of a safety integrity level requirement,definition of interlocks or permissives to be associated with aspecified type of control operation, control coding standards, preferredequipment vendors whose equipment is approved for use in the industrialcontrol project, or a preferred sequence of operations for executing aspecified type of control operation.
 10. The system of claim 1, whereinthe project analysis component is further configured to aggregatesubsets of project telemetry data, collected from multiple industrialcontrol projects, relating to vendor-specific industrial assets to yieldaggregated telemetry data, and to generate usage statistics for thevendor-specific industrial assets based on the aggregated telemetrydata, and the user interface component is configured to render the usagestatistics on a client device associated with an industrial equipmentvendor that provides the vendor-specific industrial assets.
 11. Thesystem of claim 8, wherein the usage statistics comprise at least one ofindications of which of the industrial equipment vendor's products arebeing used at customer facilities, indications of where the industrialassets are being used, indications of degrees to which availablefeatures of the industrial assets are being used in the multipleindustrial control projects, or indications of how closely theindustrial assets are being operated to their functional capacities. 12.The system of claim 1, wherein the second analysis comprises comparingthe industrial control project with a subset of archived controlprojects that perform control functions as the industrial controlproject, and the recommendation comprises an indication of an aspect ofthe industrial control project that deviates from corresponding aspectsof the subset of the archived control projects.
 13. A method foranalyzing industrial control projects, comprising: receiving, by asystem comprising a processor via a cloud platform, an industrialcontrol project comprising at least control programming and deviceconfiguration data that, in response to execution on one or moreindustrial devices, facilitate monitoring and control of an industrialautomation system; generating, by the system, project telemetry databased on a first analysis of the industrial control project, the projecttelemetry data defining characteristics of the one or more industrialdevices and predicted operating characteristics of the industrialcontrol project inferred based on the first analysis; generating, by thesystem based on a second analysis performed on the project telemetrydata and to generate, a recommendation for modifying the industrialcontrol project in a manner that improves one or more of the predictedoperating characteristics; and rendering, by the system, therecommendation on a client device.
 14. The method of claim 13, whereinthe generating the project telemetry data comprises: determining, as aportion of the project telemetry data, an inventory of the one or moreindustrial devices used in the industrial control project, anddetermining other industrial assets included in the industrialautomation system based on analysis of device configuration data for theone or more industrial devices.
 15. The method of claim 13, furthercomprising maintaining, by the system, multiple vendor-specificrepositories that store digital device profiles representing industrialassets provided by respective different equipment vendors, the digitaldevice profiles defining functional specifications for the industrialassets, wherein the generating the recommendation comprises, in responseto determining that a device profile, of the digital device profiles,corresponds to an industrial device of the one or more industrialdevices identified by the project telemetry data, generating therecommendation based on a comparison of the project telemetry data withthe device profile.
 16. The method of claim 15, wherein the generatingthe recommendation comprises generating a recommendation indicating atleast one of a replacement or reconfiguration of the industrial deviceto reduce an amount of memory or processing resources consumed by thecontrol project, a replacement or reconfiguration for the industrialdevice to increase an I/O capacity for the control project, a currentlyunused feature of the industrial device that would improve a performancemetric of the control project, or a reconfiguration of the industrialcontrol project to increase an expected lifespan of the industrialdevice.
 17. The method of claim 13, wherein the generating the projecttelemetry data comprises generating at least one of an inventory of I/Omodules or control modules used by the control project, identificationof industrial equipment connected to the I/O modules, a functionalrelationship between items of the industrial equipment or the one ormore industrial devices, an amount of available I/O utilized by thecontrol project, estimated network bandwidth consumed by the controlproject, a usage frequency of an industrial device of the one or moreindustrial devices, an estimated lifecycle for the industrial device, anestimated time-to-failure of the industrial device, an estimated amountof memory consumed by the industrial control project, an estimatedamount of energy consumed by the industrial control project, or anestimated amount of processing utilization by the control project. 18.The method of claim 13, further comprising: aggregating, by the system,subsets of project telemetry data, collected from multiple industrialcontrol projects, relating to vendor-specific industrial assets to yieldaggregated telemetry data; generating, by the system, usage statisticsfor the vendor-specific industrial assets based on the aggregatedtelemetry data; and rendering, by the system, the usage statistics on aclient device associated with an industrial equipment vendor thatprovides the vendor-specific industrial assets.
 19. A non-transitorycomputer-readable medium having stored thereon instructions that, inresponse to execution, cause a system executing on a cloud platform andcomprising a processor to perform operations, the operations comprising:receiving, via a cloud platform, an industrial control projectcomprising at least control programming and device configuration datathat, in response to execution on one or more industrial devices,facilitate monitoring and control of an industrial automation system;generating project telemetry data based on a first analysis of theindustrial control project, the project telemetry data definingcharacteristics of the one or more industrial devices and predictedoperating characteristics of the industrial control project inferredbased on the first analysis; generating, based on a second analysisperformed on the project telemetry data and to generate, arecommendation for modifying the industrial control project in a mannerthat improves one or more of the predicted operating characteristics;and rendering the recommendation on a client device.
 20. Thenon-transitory computer-readable medium of claim 19, wherein thegenerating the project telemetry data comprises: determining, as aportion of the project telemetry data, an inventory of the one or moreindustrial devices used in the industrial control project, anddetermining other industrial assets included in the industrialautomation system based on analysis of device configuration data for theone or more industrial devices.